晚上七點，阿偉走進咖啡廳的時候，整個人看起來像是被什麼重物壓過一樣。

他一屁股坐下來，把手機丟在桌上，螢幕還亮著小P的訊息：「阿偉，業務部說你做的報表功能太難用了，能不能改善一下？」

「我真的搞不懂。我這次也用了你教我的方法跟小P合作，結果咧？」他直接開門見山，「功能是順利做出來了，而且程式碼也寫得很漂亮，沒想到，那個業務部的小王卻說我這是…電子垃圾？！」

他的聲音裡帶著一種不可置信，「而且你也知道，小王這傢伙，平常講話就沒在客氣的。這次他甚至在demo會上當著我的面直接說，這個報表簡直比excel還難用。」

我點了兩杯咖啡，等他繼續說。

「我知道技術上我是站得住腳，code review的時候，老黃也說寫得不錯啊。但產品上...」阿偉挫敗地抓了抓頭髮，「我感覺自己就像個高級的打字機，雖然又快又準… 寫出的東西卻很奇怪。」

以為學會了，但還是中招

「阿偉，我先恭喜你。」我說。

他疑惑地看著我，「蛤？這要恭喜什麼，恭喜我做了一個很難用的功能嗎？」

「嗯…」我認真地說，「你確實有用之前學到的方法，跟小P合作呀。往好處看，你現在在保護自己、不再被模糊需求拖著跑這方面，已經開始熟練起來啦。這是很大的進步耶。」

阿偉看起來還是滿疑惑的，不過，至少表情稍微緩和了一點。

「那為什麼這次…我還是會出包啊？該問該釐清的我都有做啊。」

「對，你確實問了。但你有沒有發現，這次的情況跟之前，有點不一樣？」我問。

「哪裡不一樣？」

「差別就在，之前的小P給的需求都是模模糊糊的，但這次的卻很清楚。」

我拿出筆，寫下…

之前的小P：「做個即時預警功能，怎麼做？你先做做看」(需求很模糊)
這次的小P：「做個多層級自訂篩選器專門給業務部查詢，要有篩選條件選項、靈活組合搭配…」(好像是很具體的方案？)

「你看出差別了嗎？」

阿偉愣了一下，「所以...我被騙了？」

「不是騙，是你跟小P都掉進了陷阱裡啦。」我說，「之前我們學會應對的是『我不知道要什麼』的PM，但這次遇到的卻是『我以為我知道要什麼』的PM。」

我接著解釋：「小P這次很明確地說『多層級自訂篩選器』，聽起來很清楚對吧？你就照著他的『需求』問了Why、What、How much之類的細節。但問題是，這根本是小P自己想像中的解決方案。」

阿偉恍然大悟：「所以我應該要問的不是『這個篩選器怎麼做』，而是『為什麼需要篩選器』囉？」

「沒錯！」我說，「你想想看，業務部真正要的是什麼？」

「快速找到訂單...」阿偉苦笑，「結果我給了他們一個需要好幾分鐘設定的超複雜篩選器，等他們花時間找到資料，客人早就跑了。」

「這就是問題所在，我們不只要問清楚需求，還要學會質疑PM給你的方案本身對不對。」

從執行者到解決方案設計師

冰美式送上來了，阿偉喝了一口，看起來在思考什麼。

「所以我現在要學的，不只是怎麼寫更好的Code，還要判斷什麼Code值得寫囉？」他慢慢地說。

「沒錯。」我說，「還記得你小林剛來的那時候嗎？一開始小林好像看不太懂codebase，原來是因為不明白產品邏輯的緣故。」

阿偉笑了，「對。」

「現在換你了。」我說，「你寫code技術沒問題，但你要學會站在使用者的角度思考。」

我在紙上畫了三個步驟：

1. 理解真正的痛點：不是『要做什麼功能』，而是『要解決什麼問題』
2. 對既定的方案保持懷疑：問『這真的是最好的解法嗎？』『這個需求是怎麼成形的』
3. 提供替代選項：除了做PM要的之外，還得設想其他可能的備用方案

「以這次的報表功能來說，」我繼續，「如果我們當初問小P：『業務部現在找訂單遇到什麼困難？』而不是『你要哪些篩選欄位？』會怎麼樣？」

阿偉想了想，「喔… 那可能會發現，搞不好他們其實只是想要一個搜尋框，輸入客戶名稱就能找到所有相關訂單吧。」

「對！」我說，「對這時候的業務部來說，一個簡單的全文搜尋，可能比八個篩選欄位更有用。」

下次遇到這種情況怎麼辦

「那如果下次小P又給我一個『解決方案』而不是需求的話，我該怎麼辦？」阿偉問。

「嗯，我們可以這樣說…」我拿出筆記本，開始寫：

小P，我想確認一下這個功能要解決的核心問題。
現在的情況：業務部找訂單資料的時候，最常遇到什麼樣的困難？這都在怎樣的情境下發生？
我們的目標：是要讓他們能在30秒內找到想要的訂單，還是要減少他們重複查詢的次數？或是有其他原因呢？
基於這個目標，我可以提供幾個不同的技術方案供你選擇...

「你看，」我說，「這樣你就從『執行者』變成『解決方案設計師』了。你就不再只是照著做，而是主動參與思考最佳解法啦。」

阿偉的眼神亮了起來，「這樣的話，我就不只是個會寫Code的工具人，而是能提供價值的夥伴了。」

「而且，」我補充，「當你開始這樣思考，你在團隊裡的地位就不一樣了。大家會漸漸開始把你當成解決問題的人，而不單純只是執行任務的人囉。」

技術價值的翻譯術

「可是我還是有點疑問，」阿偉有點猶豫，「如果小P就是想要做這種豪華的功能，我要怎麼跟小P解釋，為什麼簡單的搜尋比複雜的篩選器更好？他可能會覺得我在偷懶耶。」

「這就回到我們之前討論過的，」我說，「我們可以運用之前向老楊預警風險、還有跨部門報告所學到的經驗，把技術價值給轉譯成小P能理解的語言。」

我在紙上寫下對比：

技術視角： 以我們公司的資料庫來說，使用全文搜尋的查詢效率，比使用多重篩選好很多

業務視角： 簡單的搜尋介面，可以讓業務同事在現場可以更方便用手機操作，而且他們在搜尋時，也不用每次都另外花心力回想和設定搜尋條件。除此之外，用搜尋框的搜尋效率更高，這樣一來，找訂單的時間可以從約2分鐘縮短到5秒以內

「用時間成本、操作步驟這些他能理解的指標來說明，」我說，「而不是直接去跟他講演算法複雜度。」

阿偉點點頭，「我懂了。就像我跟老楊解釋技術債，要用現實場景中的影響來說明一樣。」

「沒錯。而且當我們能這樣溝通時，就開始具備產品思維了喔。」我說，「你開始關心的不只是code怎麼寫，還有code寫出來的東西對誰有用、有什麼用，這樣一來我們寫的code是不是就更實用了呢？」

把程式碼轉換成實際的價值

咖啡廳裡的人潮漸漸散去，阿偉看起來心情好像也好了很多。

「我一直以為，產品思維是PM或老闆才需要懂的東西。現在才發現，原來工程師也需要啊。」

「嗯，需要喔！」我說，「而且畢竟你是裡面最懂技術可行性的人，如果你不參與產品決策，那就很容易做出技術上完美、產品上卻失敗的東西了。」

「就像這次的報表功能，」阿偉扶著額頭苦笑，「Code review得滿分，使用者體驗…零分。哈哈，我真是要被自己蠢哭啦。」

「沒關係啦。」我拍拍他，「至少下次遇到類似情況，我們就知道要主動去了解使用者的真實需求，然後提供最適合的技術方案啦。」

阿偉收拾筆記本準備離開時，回頭對我說：「我終於懂了，其實寫code只是我工作的一部分，真正的目的應該是利用我寫出來的code，來解決使用者的問題才對。」

看著他走出咖啡廳的背影，我想起第一次聊天時，那個不知所措的阿偉。

現在的他，應該已經準備好迎接更大的挑戰了吧。